Chris Pollett > Old Classes >
CS175

( Print View )

Student Corner:
  [Grades Sec1]

  [Submit Sec1]

  [
Lecture Notes]
  [Discussion Board]

Course Info:
  [Texts & Links]
  [Topics/Outcomes]
  [Outcomes Matrix]
  [Grading]
  [HW/Quiz Info]
  [Exam Info]
  [Regrades]
  [Honesty]
  [Additional Policies]
  [Announcements]

HWs and Quizzes:
  [Hw1]  [Hw2]  [Hw3]
  [Hw4]  [Hw5]  [Quizzes]

Practice Exams:
  [Mid]  [Final]

                           












HW#2 --- last modified February 07 2019 04:23:36..

Solution set.

Due date: Oct 10

Files to be submitted:
  Hw2.zip

Purpose:

Related Course Outcomes:

LO1 -- Create a working mobile phone application and test it both in a simulator and on a mobile device.

LO2 -- Write a mobile application that involves GUI components and makes use of touch events to manipulate these components.

LO5 -- Write a mobile application that stores program data persistently using an API like sqlite.

Specification:

For this homework you will write a game called DizzyPhone. You can write this for either iOS or Android and as usual there is 1 bonus point for writing it for two platforms (which may include HTML 5). DizzyPhone when launched should have a start screen on which there are two buttons: Start Game and Settings. On the Settings screen there should be a label saying Player Name with a text field next to it, beneath this there should be a slider with range between 2 seconds and 0.1 seconds with a label next to it saying Game Speed. The default values for these should be Player1 and 1 second respectively. At the button of the screen there should be a button saying Return. Clicking return should launch a dialog/action sheet where the user can choose to save these values or go back to the main screen without saving. Saving these values means saving the values using one of the app persistence mechanisms discussed in class, so that they will be remembered between times this app is run. Back on the start screen if Start Game is clicked, then on the screen we see at the top we see a score label, a High label (for high score) and a label Lives and a number of lives up to 3. In the center of the screen appears at random either the word Landscape or Portrait (we don't distinguish between up or down) and beneath this a button I'm there. The user then has the time given in settings to switch the phone to that orientation and click the I'm there button. Timing can be done with NSTimer for iPhone, Handler class in Android, or setTimeout/setInterval in Javascript. If the user fails to switch the orientation, one life is taken away, if they succeed one point is added to their score. If the user has no lives left the game is over. When the game is over, it should print a screen with game over on it for 10 seconds then go back to the start screen. High scores should persist between runs of the game. To test out writing things to your devices log, whenever the screen orientation changes your app should write an informational log message saying what the orientation has changed to.

Since one of the goals of this class is to actually make apps that get on devices, on the due date of the homework I'll ask you to demo your app on a mobile device.

To submit this homework, use the technique described on the discussion page. If you already created a Yioop group with the grader for HW1 you don't need to create a new group, just add a new wiki page, this time for Hw2.

At the same time this homework is due I want you to start working on the Cinequest app. Your group should choose either to work on the Android version of the app or iOS version. You should fork the current Cinequest Android or iPhone project from the git repository (1/2pt toward Cinequest score). You should clone your fork and compile the result and take a screen shot of it on the simulator/emulator (1/2pt - beware, at least on my iPad the app now crashes in iOS 8). On your Hw2 wiki page for your group put this screen shot and a screen short of your fork. You should then write down notes where you try to list out the different classes you see while looking at the various files in this project. For each class write roughly what its for (1/2). Each team member should find an under-documented class, add comments for that class, commit, and push the result the result back to your fork. You should then initiate a pull request of your changes to the original repository (1/2pt).

Point Breakdown

Demo of code running on device 1pt
Launch screen as described with start and setting buttons working (1/2pt each). 1pt
Settings page as described. 1pt
Persistence of name, slider, and high score data. 1pt
Slider value used to set how long a person has to change the screen and click button during game play. 1pt
Game play as described. 1pt
Lives works as described. 1pt
Game scoring works as described. 1pt
Game over works as described. 1pt
Log messages on screen orientation change. 1pt
Total10pts